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Security of Messages Exchanged between Servers and Relay Agents 
Abstract 


The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has no 
guidance for how to secure messages exchanged between servers and 
relay agents. The Dynamic Host Configuration Protocol for IPv6 
(DHCPv6) states that IPsec should be used to secure messages 
exchanged between servers and relay agents but does not require 
encryption. With recent concerns about pervasive monitoring and 
other attacks, it is appropriate to require securing relay-to-relay 
and relay-to-server communication for DHCPv6 and relay-to-server 
communication for DHCPv4. 
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This is an Internet Standards Track document. 
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received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc8213. 


Copyright Notice 


Copyright (c) 2017 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 


Volz & Pal Standards Track [Page 1] 


RFC 8213 DHCP Relay/Server Security August 2017 


This document may contain material from IETF Documents or IETF 
Contributions published or made publicly available before November 
10, 2008. The person(s) controlling the copyright in some of this 
material may not have granted the IETF Trust the right to allow 
modifications of such material outside the IETF Standards Process. 
Without obtaining an adequate license from the person(s) controlling 
the copyright in such materials, this document may not be modified 
outside the IETF Standards Process, and derivative works of it may 
not be created outside the IETF Standards Process, except to format 
it for publication as an RFC or to translate it into languages other 
than English. 


Table of Contents 


Te ENE ROAUCELONY o eca gestae 4 Se wee la eae Seed Sree Baye Spee ee Sed GS a pee Sta le eed eek 2 
2. Requirements Language and Terminology ...........- eee eee eee eee eee 3 
3. Security of Messages Exchanged between Servers and Relay 

PGS TSE sien gh cnet a at aaa vam hee eget Ne a Be ra ak cee agp a a dome aE ties N hae RAE Site. SETS 3 
4. SC CUuracy \Gonstderat ons is 4 Mist tte tele che es Mss aoe Beles gt he 5 
S53, LANA Considerations: da o-chide dea esicd argh ie onset at rat foe be lente ve seh tear ep a n E a owlesy abe 5 
6a VRELS LENSES e aari a e a ae aA ocean sai pa val atta ver I er a tories CAN a Venton AIE ese Wane ce Mebvainewey eles 6 

671-3. Normatives “REFETENCES arasso is. ai etre aie ele Re we ete eee, were we Mate oe er ese be 6 

6.26 -Informative References soo.0 sie eee eee oes wR eee ES See Re ee 6 
AGKNOWLEAQGMENTS: Lae 58 Bie cee eer Bal en bie ode Sele aude tesa e Bee Le el Scere eee bee ORG E 8 
Authors? “Addresses 26 sce ead ee ewe ied a aaa ag bee erieieee Biel gee eset es gs S 8 

1. Introduction 


The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) [RFC2131] 
and the Bootstrap Protocol [RFC1542] have no guidance for how to 
secure messages exchanged between servers and relay agents. The 
Dynamic Host Configuration Protocol for IPv6é (DHCPv6) [RFC3315] 
states that IPsec should be used to secure messages exchanged between 
servers and relay agents but does not recommend encryption. With 
recent concerns about pervasive monitoring [RFC7258], it is 
appropriate to require use of IPsec with encryption for relay-to- 
server communication for DHCPv4 and require use of IPsec with 
encryption for relay-to-relay and relay-to-server communication for 
DHCPv6. 


This document specifies the optional requirements for relay agent and 


server implementations to support IPsec authentication and encryption 
and recommends that operators enable this IPsec support. 
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2. Requirements Language and Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in BCP 
14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


This document uses terminology from [RFC1542], [RFC2131], and 
[RFC3315]. 


3. Security of Messages Exchanged between Servers and Relay Agents 


For DHCPv6 [RFC3315], this specification REQUIRES relay and server 
implementations to support IPsec encryption of relay-to-relay and 
relay-to-server communication as documented below. The remainder of 
this section replaces the text in Section 21.1 of [RFC3315] when this 
specification is followed. 


For DHCPv4 [RFC2131], this specification REQUIRES relay and server 
implementations to support IPsec encryption of relay-to-server 
communication as documented below. 


This specification RECOMMENDS that operators enable IPsec for this 
communication. 


By using IPsec with encryption for this communication, potentially 
sensitive client message and relay included information, such as the 
DHCPv4 Relay Agent Information option (82) [RFC3046], vendor-specific 
information (for example, the options defined in [CableLabs-DHCP]), 
and Access-Network-Identifier option(s) [RFC7839], are protected from 
pervasive monitoring and other attacks. 


Relay agents and servers MUST be able to exchange messages using the 
IPsec mechanisms described in [RFC4301] with the conditions below. 
If a client message is relayed through multiple relay agents (relay 
chain), each of the relay agents MUST have established independent, 
pairwise trust relationships. That is, if messages from client C 
will be relayed by relay agent A to relay agent B and then to the 
server, relay agents A and B MUST be configured to use IPsec for the 
messages they exchange, and relay agent B and the server MUST be 
configured to use IPsec for the messages they exchange. 
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Relay agents and servers use IPsec with the following conditions: 


Selectors 


Mode 


Relay agents are manually configured with the 
addresses of the relay agent or server to which DHCP 
messages are to be forwarded. Each relay agent and 
server that will be using IPsec for securing DHCP 
messages MUST also be configured with a list of the 
relay agents to which messages will be returned. 

The selectors for the relay agents and servers will 
be the pairs of addresses defining relay agents and 
servers and the direction of DHCP message exchange 
on DHCPv4 UDP port 67 or DHCPv6 UDP port 547. 


Relay agents and servers MUST use IPsec in transport 
mode and use Encapsulating Security Payload (ESP). 


Encryption and authentication algorithms 


Key management 


Security policy 


Authentication 
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This document REQUIRES combined mode algorithms for 
ESP authenticated encryption, ESP encryption 
algorithms, and ESP authentication algorithms as per 
Sections 2.1, 2.2, and 2.3 of [RFC7321], 
respectively. Encryption is required as relay 
agents may forward unencrypted client messages as 
well as include additional sensitive information, 
such as vendor-specific information (for example, 
the options defined in [CableLabs-—DHCP]) and the 
Access-Network-Identifier Option defined in 
[RFC7839]. 


Because both relay agents and servers tend to be 
managed by a single organizational entity, public 
key schemes MAY be optional. Manually configured 
key management MAY suffice but does not provide 
defense against replayed messages. Accordingly, 
Internet Key Exchange Protocol Version 2 (IKEv2) 
[RFC7296] with pre-shared secrets SHOULD be 
supported. IKEv2 with public keys MAY be supported. 
Additional information on manual vs. automated key 
management and when one should be used over the 
other can be found in [RFC4107]. 


DHCP messages between relay agents and servers MUST 
only be accepted from DHCP peers as identified in 
the local configuration. 


Shared keys, indexed to the source IP address of the 
received DHCP message, are adequate in this 
application. 
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Note: As using IPsec with multicast has additional complexities (see 
[RFC5374]), relay agents SHOULD be configured to forward DHCP 
messages to unicast addresses. 


4. Security Considerations 


The security model specified in this document is hop by hop. For 
DHCPv6, there could be multiple relay agents between a client and 
server, and each of these hops needs to be secured. For DHCPv4, 
there is no support for multiple relays. 


As this document only mandates securing messages exchanged between 
relay agents and servers, the message exchanges between clients and 
the first-hop relay agent or server are not secured. Clients may 
follow the recommendations in [RFC7844] to minimize what information 
they expose or make use of secure DHCPv6 [SEC-DHCPv6] to secure 
communication between the client and server. 


As mentioned in Section 14 of [RFC4552], the following are known 
limitations of the usage of manual keys: 


o As the sequence numbers cannot be negotiated, replay protection 
cannot be provided. This leaves DHCP insecure against all the 
attacks that can be performed by replaying DHCP packets. 


o Manual keys are usually long lived (changing them often is a 
tedious task). This gives an attacker enough time to discover the 
keys. 


It should be noted that if the requirements in this document are 
followed, while the DHCP traffic on the wire between relays and 
servers is encrypted, the unencrypted data may still be available 
through other attacks on the DHCP servers, relays, and related 
systems. Securing these systems and the data in databases and logs 
also needs to be considered on both the systems themselves and when 
transferred over a network (i.e., to network attached storage for 
backups or to operational support systems). 


Use of IPsec as described herein is also applicable to Lightweight 
DHCPv6 Relay Agents [RFC6221], as they have a link-local address that 
can be used to secure communication with their next-hop relay (s). 


5. IANA Considerations 


This document makes no request of IANA. 
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